Usenet 1993 July/InfoMagic USENET CD-ROM July 1993.ISO/sources/std_unix/v21/174.a.diff

Text File | 1990-12-05 | 16.2 KB | 392 lines

389 vn/174 vn/174.a
1c1
< From [e-mail]  Wed Oct  3 11:08:06 1990
---
> From [e-mail]  Wed Oct  3 11:21:46 1990
3,4c3,4
<     id AA14297; Wed, 3 Oct 90 11:08:06 -0400
< Posted-Date: 3 Oct 90 15:46:12 GMT
---
>     id AA18463; Wed, 3 Oct 90 11:21:46 -0400
> Posted-Date: 3 Oct 90 14:58:36 GMT
6c6
< From: [e-mail] (Jason Zions)
---
> From: [e-mail] (Jeffrey S. Haemer)
8,14c8,10
< Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
< Message-Id: <[e-mail]>
< Sender: [e-mail]
< Organization: Hewlett Packard, Information Networks Group
< Subject-References: <[e-mail]> <[e-mail]>
< X-Submissions: [e-mail]
< Date: 3 Oct 90 15:46:12 GMT
---
> Subject: Standards Update, X3J16: C++
> Message-Id: <[e-mail]>
> Sender: [e-mail]
15a12,14
> Organization: USENIX Standards Watchdog Committee
> X-Submissions: [e-mail]
> Date: 3 Oct 90 14:58:36 GMT
18c17
< Submitted-by: [e-mail] (Jason Zions)
---
> Submitted-by: [e-mail] (Jeffrey S. Haemer)
20c19
< Dominic Dunlop says:
---
>            An Update on UNIX1-Related Standards Activities
22,28c21
< > I dare say that, as more types of object appear in filename space (and
< > I, for one, should like to see them do so), the question of determining
< > uniqueness will become knottier.  Suppose, for example, that one used
< > filenames as handles for virtual circuits across a wide-area network.
< > Conceivably, the number of such circuits could be sufficiently large
< > that it will become difficult o shoe-horn a unique identifier into the
< > existing stat structure fields.  A problem for the future?
---
>                            October 3, 1990
30,40c23
< Actually, a problem for today. P1003.8 has to cope with the fact that a
< local file for major 0, minor 0x010100, inode 1234 is *different* from a
< file on some remote machine with the same (major,minor,inode) triplet. But
< adding a new field or fields to the stat structure isn't gonna work;
< expanding that structure will cause many implementations to shatter (i.e.
< break spectacularly). Just cobbling up a major number for some random
< remotely-mounted filesystem is unsatisfactory, unless the cobble is
< persistant over umount/mount operations. (An application starts to run;
< opens file1 on remsys, gets (maj,min,ino). Network goes down, comes up;
< system remounts remsys. App opens file2 on remsys. That major number had
< better be the same for remsys!)
---
>                  USENIX Standards Watchdog Committee
42,48c25
< What's needed is a simple routine which can be called to determine if two
< handles point to the same object. It would be nice if there was a routine
< which took as arguments a file handle and a path name and returned true iff
< the path referred to the same file. This routine would be guaranteed by the
< implementor to work for any file-system resident object provided for; e.g.
< an SVR4 implementation would have to be able to tell if a file opened via
< RFS referred to the same underlying file as one opened under NFS.
---
>           Jeffrey S. Haemer <[e-mail]>, Report Editor
50,53c27
< I don't know if that's sufficient, though; application programmers may be
< using the stat info for other purposes, and a remote_addr field might be a
< good idea. Once P1003.12 decides on a representation for an arbitrary
< network address, which might be considerably larger than an IP address.
---
> X3J16: C++
55c29,336
< Jason Zions
---
> Mike Vilot <[e-mail]> reports on the July meeting in
> Seattle, Washington:
>
> Standard C++?
>
> The C++ programming language has been gaining popularity at a
> remarkable rate (an informal estimate is that the C++ population
> doubles every nine months).  One reaction to the growing popularity
> has been a call to stabilize the language's definition, and achieve
> some consistency across implementations.  C++ is popular enough that
> larger corporations are considering adopting it as an officially
> endorsed development language -- but some cannot make such a move
> unless the language is defined by a standard.
>
> For these and other reasons, the ANSI secretariat agreed to establish
> the X3J16 committee to formulate a standard for C++.  Dmitry Lenkov,
> of HP, made the official proposal, and serves as chairman of the
> committee.  To date, X3J16 has met three times: an organizational
> meeting last December, the first technical meeting in March to get
> organized, and a meeting in July to really get started.
>
> The December meeting, in Washington D.C., was purely administrative:
> over 50 attendees received lectures and tons of paper on X3 rules and
> procedures.  The highlight of the day was an invited presentation by
> Bjarne Stroustrup on ``the spirit of C++.'' The transcript is
> available as committee document X3J16/90-0022 or from Greg Comeau at
> Comeau Computing, 91-34 120th Street, Richmond Hill, NY 11418, (718)
> 849-2355.
>
> March meeting
>
> AT&T hosted the meeting in New Jersey.  Most of the week was spent on
> administrative matters, while the group got organized and accustomed
> to The Bureaucratic Way.  Since most of the members are engineers, the
> highlight of the week was the evening technical sessions on
> implementing exception handling for C++.  (The week was sort of a
>
> __________
>
>  1. UNIXTM is a Registered Trademark of UNIX System Laboratories in
>     the United States and other countries.
>
> October 3, 1990 Standards Update                            X3J16: C++
>
>
>                 - 2 -
>
> mini-Usenix conference, as most members had gone without a substantial
> C++ gathering since the October '88, Denver conference.)
>
> The week's major activities were discussing and preparing a goals
> document, describing the committee's activities and priorities.
>
> Goals
>
> Here is a brief outline of the goals document, which is available as
> X3J16/90-0023:
>
>   1.  Base documents: C++ Reference Manual, ANSI C (ANS X3.159-1989),
>       ISO C when available.
>
>   2.  Standardize syntax and semantics of the language as a token
>       sequence without the presence of preprocessing directives.
>
>   3.  Define and standardize a minimum set of C++ libraries, their
>       contents, and interfaces.
>
>   4.  Standardize elements of a C++ environment.
>
>   5.  Consider proposed major changes: parameterized types and
>       exceptions.
>
>   6.  Ensure that the standard is suitable for the international
>       community.
>
>   7.  Ensure a very high level of compatibility with ANSI C.
>
>   8.  Establish coordinating liaisons with X3J11 (ANSI C) and
>       Numerical C Extensions Group.
>
>   9.  Produce two deliverables: draft proposed standard and rationale.
>
>  10.  Priorities:
>
>          - clear & unambiguous
>
>          - C++ reference manual
>
>          - other base documents
>
>          - consistency
>
>          - user/implementer experience
>
>          - portability, efficiency, expressiveness
>
>          - ease of implementation (including translation to C)
>
> October 3, 1990 Standards Update                            X3J16: C++
>
>
>                 - 3 -
>
> There was some confusion over the multiple base documents.  Most
> members had seen the AT&TT C++ version 2.0 reference manual, but in
> preparation for standardization, the language and its reference manual
> had suffered a number of subsequent, small changes.  AT&T made the 2.1
> reference manual available to X3J16; it was essentially the text of
> the book The Annotated C++ Reference Manual by Margaret Ellis and
> Bjarne Stroustrup published by Addison-Wesley (minus the annotations).
>
> My naive suggestion to remove the ANSI C standard as a base document
> in favor of a single base provoked the most intense and emotional
> discussion of the week.  At stake was compatibility between C++ and C.
>
> While most members of X3J16 feel that the existence of a separate
> committee implies the standardization of a new language, some former
> members of X3J11, which just finished the C standard, want to
> eliminate any and all incompatibilities with C.  (There was even a
> threat to sabotage the C++ standard in balloting if they are not
> removed.)
>
> This issue is obviously important and has two sides.  Make your
> preferences known to the committee.  For detailed reference material,
> both ``C++: As Close as Possible to C -- But No Closer,'' (Bjarne
> Stroustrup and Andy Koenig, The C++ Report, 1(7), 1989) and Chapter 18
> of The Annotated C++ Reference Manual document and explain differences
> and incompatibilities between the languages as they stand today.
>
> Focusing on a language without preprocessing directives continues the
> de-emphasis of the C preprocessor.  This is particularly favored by
> C++ vendors looking into more powerful development environments.
> [Editor: Admittedly, improper preprocessor use can sink us in deep and
> dirty bath water, but let's make sure to save the baby.  When writing
> portable C, I personally find #ifdefs extremely valuable; I suspect
> they will remain valuable in C++, and I would hate to see the working
> group neglect this valuable porting tool.]
>
> The libraries effort includes asking what to do about the ANSI-C
> library, and investigating what can be standardized in a more C++-like
> approach.
>
> The environment work addresses the linking and executing of C++ code
> with non-C++ code (i.e., linkage and program execution models), rather
> than development environment tools.
>
> There are thousands of suggested ``improvements'' proposed as
> extensions to C++, but there is consensus on two named in the goals
> document: parameterized types and exception handling.  Their proposals
> are detailed, and both have been implemented (in some form) in a few
> C++ implementations.
>
> The emphasis on international concerns reflects the lessons learned
> from the difficulties of C standardization.  X3J16 has some fences to
>
> October 3, 1990 Standards Update                            X3J16: C++
>
>
>                 - 4 -
>
> mend, particularly in the international community.  Rather than
> waiting until the last minute to spring a standard on the ISO, the C++
> committee is involving itself with the international community right
> from the start.
>
> July meeting
>
> Microsoft hosted the second, Seattle meeting.  Sub-groups focused on
> the key topics listed in the goals statement began work at the March
> meeting, and reported their progress in Seattle.
>
> International Concerns
>      Steve Carter, of Bellcore, presented the major International
>      Concerns (particularly character sets and formal specification)
>      and asked the other groups to work on these issues.  He also
>      suggested various sites overseas where future X3J16 meetings
>      could help cooperation with international standardization
>      efforts.
>
> Editorial
>      Jonathan Shopirio, of AT&T, presented the Editorial group's
>      proposal for organizing and formatting the standard.  Jon is also
>      working on an abstract machine model, and a way to define the
>      semantics in the standard precisely and consistently.
>
> Formal Syntax
>      James Roskind, an independent consultant, presented the work of
>      the Formal Syntax group.  He has developed (and published on the
>      net) a yacc-able grammar for C++, and is concerned about
>      ambiguities in the the language.  Most of the discussion was
>      spent trying to discover whether C++ can (or should) be made
>      LALR(1).
>
> Core Language
>      Andy Koenig, of AT&T, presented the Core Language group's work.
>      Initially, they identified and classified difficulties in the
>      working document.
>
> Environment
>      John Vasta, of HP, presented the work of the Environment group.
>      A key issue addressed by this group is the interaction of C++
>      with other programming languages.  Among the important topics are
>      linkage of C++ and non-C++ translation units, especially the
>      construction and destruction of static C++ objects.
>
> Libraries
>      I presented the Library group's work.  There were many
>      suggestions, from both inside and outside of the committee.
>      (Interested outside suggesters were James Coggins, Keith Gorlen,
>      and Doug Lea, who have each developed large C++ libraries.) A few
>      people noted similarity with topics covered by other standards
>
> October 3, 1990 Standards Update                            X3J16: C++
>
>
>                 - 5 -
>
>      (notably POSIX).  Initially, the library group will focus on a
>      few commonly-used components.  Parameterized types and exception
>      handling will significantly effect the way we design libraries in
>      C++.
>
> Language Extensions
>      Bjarne Stroustrup, of AT&T, presented the work of the Extensions
>      group, which was by far the most active.  The technical sessions
>      presented experience with implementation and use of the template
>      facility.
>
>      The most active and emotional debate of the week was on exception
>      handling, discussing the proposal outlined by Andy Koenig and
>      Bjarne Stroustrup in their paper ``Exception Handling for C++''
>      presented at the Usenix C++ conference in April.  Martin
>      O'Riordan, of Microsoft, and Mike Miller, of Glockenspiel,
>      presented arguments in favor of extending the current proposal
>      (which defines termination semantics for exceptions) to include
>      resumption semantics.  Andy and Bjarne explained their reasons
>      for not including resumption -- the most important was the
>      complexity and cost of implementation.
>
>      To their credit, the group worked hard to find a proposal that
>      provided both kinds of exceptions with acceptably small
>      time/space overhead.  However, at the end of the week, Bjarne
>      declared the debate deadlocked, and refused to impose his
>      proposal while substantial disagreement remained.  This is
>      another topic where you should make your opinions heard.
>
> C Compatibility
>      Mike Miller presented the work of the C Compatibility group.  Tom
>      Plum, of Plum-Hall, produced a list of every section of the C++
>      reference manual that was not C.  Much of the group's near-term
>      activity will be devoted to explaining the many items on the
>      list.
>
> The Seattle meeting produced tangible progress on the language
> standard.  X3J16 voted to accept the proposed document outline and
> format.  They also agreed to incorporate the template proposal (the
> text from Chapter 14 of The Annotated Reference Manual, minus the
> annotations -- it was literally a scissors-and-tape job).  We hope C++
> vendors will regard templates as now officially in the language, and
> provide users an opportunity to work with this feature.
>
> Next events
>
> A few substantial issues lie ahead.  The next meeting should see some
> resolution on the exception proposal.  We should see some progress on
> the review of language ambiguities and inconsistencies, and have some
> idea of how difficult it will be to ANSIfy the document.  We should
> also see some specific proposals on library contents.  The most
>
> October 3, 1990 Standards Update                            X3J16: C++
>
>
>                 - 6 -
>
> substantial will be a simplified version of iostreams by Jerry Schwarz
> (now at Stardent, formerly at AT&T).
>
> Our target date for delivering a draft standard is the end of 1992.
> X3J16 meets three times per year.  The next three meetings (and their
> hosts) will be:
>
>    + November 12-26, Cupertino CA (Hewlett Packard)
>
>    + March 11-15, Nashua NH (Digital)
>
>    + June 17-21, Lund Sweden (Lund Institute of Technology)
>
> Membership on an X3 committee is open to any individual or
> organization with expertise and material interest in the topic
> addressed by the committee.  The cost for membership is $250.  Contact
> the chair or vice chair for details.
>
> Chair: Dmitry Lenkov
> HP California Language Lab
> 19447 Pruneridge Avenue MS 47 LE
> Cupertino, CA  95014
> [phone]
> FAX [phone]
> email [e-mail]
>
> Vice Chair: William M.  Miller
> Glockenspiel, Ltd
> P.O. Box 366
> Sudbury, MA  01776-0003
> [phone]
> email [e-mail]
>
> October 3, 1990 Standards Update                            X3J16: C++